The generated GetObjectData override on F# exception types must have the
[SecurityCritical] attribute to match the security accessibility of
Exception.GetObjectData on .NET Framework. Without this, the CLR rejects
the override with 'Inheritance security rules violated', causing FS0193
errors when any project references FSharp.Core (which contains
MatchFailureException with the new GetObjectData override).

Also update IL baselines and FSharp.Core surface area baseline.

Co-authored-by: Copilot <[email protected]>

FSharp.Core has [assembly: SecurityTransparent] which makes all methods
transparent. On .NET Framework, transparent methods cannot override
SecurityCritical methods (Exception.GetObjectData) nor call SecurityCritical
base constructors (Exception(SerializationInfo, StreamingContext)).
Skip emitting serialization members for FSharp.Core exceptions.

Co-authored-by: Copilot <[email protected]>

…, add test

FSharp.Core has [assembly: SecurityTransparent]. On .NET Framework,
transparent code cannot override SecurityCritical methods (GetObjectData).
Without GetObjectData to write fields, the field-restoring ctor would crash.

So for FSharp.Core exceptions:
- Keep the base-call-only deserialization ctor (status quo, SecuritySafeCritical base)
- Skip GetObjectData override (can't override SecurityCritical from transparent)

For user exceptions (no SecurityTransparent):
- Emit both GetObjectData and field-restoring ctor (full serialization)

Add test verifying FSharp.Core MatchFailureException:
- Loads without TypeLoadException
- Has deserialization ctor
- Does NOT have GetObjectData override

Co-authored-by: Copilot <[email protected]>

The compilingFSharpCore guard skips GetObjectData, so the surface area
baseline should not include it for MatchFailureException.

Co-authored-by: Copilot <[email protected]>

Co-authored-by: Copilot <[email protected]>

…ctors

Add deserialization constructor bodies (reading fields from SerializationInfo)
and GetObjectData overrides to match the netcore baselines.

Co-authored-by: Copilot <[email protected]>

Changed eventsWhen condition in 'Cancel running jobs with the same key'
test to wait until all 10 outdated jobs are canceled and the new job
finishes, instead of stopping at the first Finished event. This prevents
race conditions where assertions run before all cancellations complete.

Co-authored-by: Copilot <[email protected]>

…issue #18411)

Co-authored-by: Copilot <[email protected]>

Use IL backing field name (with @ suffix) as the serialization key
instead of the property name. This prevents duplicate key crashes when
an F# exception field name collides with a key already used by
Exception.GetObjectData (e.g., 'exception Foo of Message:string').

The backing field name (e.g., 'Message@', 'Data0@') is guaranteed
to not collide with base Exception serialization keys.

Co-authored-by: Copilot <[email protected]>

Add Issue_878_ExceptionSerialization_MessageFieldCollision test that
reproduces the exact edge case where an F# exception field named
'Message' collides with Exception.GetObjectData's 'Message' key.

The test verifies:
- GetObjectData does not throw with duplicate key
- F# field is serialized under backing field name 'Message@'
- Base Exception's 'Message' key remains accessible
- Full serialization roundtrip preserves the field value

Co-authored-by: Copilot <[email protected]>

- Eliminate ilBaseOnlyCtorInstrs/ilBaseOnlyCtor block that duplicated
  ilInstrsForSerialization/ilCtorDefForSerialization by introducing
  shouldRestoreFields flag
- Simplify 3-branch if/elif/else to 2-branch conditional
- Remove unused ilPropName parameter from emitSerializationFieldIL callback

Co-authored-by: Copilot <[email protected]>

Co-authored-by: Copilot <[email protected]>